This is supported in Nimbus as of v22.3 for anyone that wants to test it on the execution side.

Are you sure that browsers do not allow setting the Authorization header for connections to 127.0.0.1?

Web pages can set headers in requests made by JS, but certain headers are forbidden when they have low-level meaning or when they are part of the security framework of the web platform: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name
Authorization is not on that list though.

@fjl my wording was a little confusing, but browsers strip Authorization for cross-origin requests: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization

So a random website trying to call 127.0.0.1 will not be able to include that header.

As discussed, I think stripping does not occur, and websites can in fact set this header. In general, the security of our mechanism should probably not lean into the browser's security model too much.

In general, the security of our mechanism should probably not lean into the browser's security model too much.

That's not how In interpret the proposition.

BUT: the proposition is that 'anyone who can send data to localhost to address the api'. And a typical way that could be exploited, would be if a victim accesses a malicious webpage, and that webpage manages to trigger the browser to interact with the protected api. And the question is if such an attack is possible. And the answer is that it should not be possible, due to the regulations for the ability of webpages for setting arbitrary headers.

So basically, in order to evaluate this possible attack, we must consider the browser security model.

Yes, if we are specifically concerned about browser-based attacks, we could rely on the defenses implemented by browsers. But it's still a fine line to walk, because relying on these also means we will be affected by any breach of cross-origin request prevention. What I was trying to say is, best if we don't rely on that at all. I think #297 is a better alternative.

Late to the party, but it is not uncommon to have App A bound to 127.0.0.1 and then a reverse proxy server bound to 0.0.0.0 which blindly forwards all requests to App A. I like the idea behind this proposal, but I think in reality listening only to 127.0.0.1 is not sufficient to be sure outside requests won't make it to the server.

Late to the party, but it is not uncommon to have App A bound to 127.0.0.1 and then a reverse proxy server bound to 0.0.0.0 which blindly forwards all requests to App A.

This is quite nuts though as far as setups go and requires explicit action not unlike jwt itself - we're trying to protect "default"/simple setups from fishy web sites, not users that go out of their way to open their host to the world.

The JWT file remains one of the top contenders for broken setups in terms of user support - it is not a "free security feature" but rather a poorly understood (by users) and complex mechanism - in these discussions, it's important remembering this is not at all free in terms of how much (economic) damage it is actively causing in terms of user support, downtime due to setup problems, higher barrier of entry etc. If we want home staking, UX research in this area would be much welcome.

The default CORS policy in EL clients prevents requests from browsers and I think this provides enough of a protection for the concerns raised here, but there are some reasonable ways to improve the security. We can derive the default JWT value from system-specific pieces of information that are easy to obtain from system software, but not accessible from browsers. Some examples would include the MAC address of the first network interface, the first CPU serial number, etc.